When FormatCollectionPreview catches an exception during enumeration, it forces truncated = elements.Count > 0, but enumeratedCount may equal displayedCount (e.g., exception thrown after the last successfully added element). In that case remaining becomes 0 and the preview can end up with ... 0+ more, which is misleading. Consider tracking whether enumeration was actually cut short (e.g., a separate failedEnumeration flag) and only append the ... N more suffix when remaining > 0, or use a non-numeric suffix for the “unknown remainder due to enumeration failure” case.

ReplaceNulls now returns an empty string when input is null, which will produce blank values in assertion messages that still use ReplaceNulls (e.g., mismatched element reporting in CollectionAssert). Consider returning a consistent null token (e.g., "null" or FrameworkMessages.Common_NullInMessages) so nulls are visible in formatted output.

This issue also appears on line 116 of the same file.

The nullability-mismatch failure message is currently hardcoded ("Expected collections to be equivalent." and "null/not null"), while most other assertion messages are coming from FrameworkMessages.resx. To keep assertion output localizable and consistent, consider moving these strings into resources (and using the same null token as the rest of the formatter).

See below for a potential fix:

        if ((expected is null) != (actual is null))
        {
            string msg = "Expected collections to be equivalent.";
            msg += Assert.FormatAlignedParameters(
                new Assert.StringPair("expected", expected is null ? Assert.ReplaceNulls(null) : "not null"),
                new Assert.StringPair("actual", actual is null ? Assert.ReplaceNulls(null) : "not null"));

The equality diagnostic hint strings ("Objects are equal." / "Objects are not equal.") are hardcoded. Since assertion messages are generally localized via FrameworkMessages.resx, consider moving these hint fragments into resources (or otherwise ensuring they follow the same localization strategy).

Assert.That now builds several user-facing failure sentences via hardcoded interpolated strings (e.g., "Expected {x} to be false/true" and the comparison messages). If this framework’s assertion output is intended to be localizable (as suggested by the extensive FrameworkMessages.resx usage), these new strings should also be moved into resources for consistency and localization coverage.

TryEvaluateFormatted compiles and executes sub-expressions (Expression.Lambda(expr).Compile().DynamicInvoke()), which can re-run user code after the initial condition.Compile()() evaluation. This can cause side effects (methods invoked twice), performance regressions, or different results if expressions are non-deterministic. Consider limiting evaluation to safe expression types (constants/member access) or avoid executing method calls when building the failure message.

FormatValue<T>(T? value, int maxLength = 256) ignores the maxLength argument for IEnumerable values because it calls FormatCollectionPreview(enumerable) without passing maxLength. This makes FormatValue(..., maxLength: X) behave inconsistently depending on the runtime type. Pass maxLength through to FormatCollectionPreview (and/or document that collections are always formatted with a fixed limit).

ThrowAssertIsInRangeFailed receives minValueExpression and maxValueExpression but never uses them. This makes the signature misleading and increases the chance of future callers assuming those expressions affect the output. Either remove these parameters or include them in the call-site/details (e.g., show the full call site / range expression).

Contains<T> materializes non-ICollection enumerables ([.. collection]) before checking membership. This forces full enumeration even when the expected item is found early, which is a behavior and performance regression (and can surface iterator side-effects/exceptions that previously wouldn't occur on passing assertions). Consider iterating once and returning as soon as the item is found, only buffering elements when you need to build the failure message (or only materializing on the failure path).

This issue also appears in the following locations of the same file:

• line 298
• line 385
• line 518
• line 627

See below for a potential fix:

        if (collection is ICollection<T> collectionOfT)
        {
            if (!collectionOfT.Contains(expected))
            {
                ThrowAssertContainsItemFailed(message, expectedExpression, collectionExpression, collectionOfT);
            }

            return;
        }

        List<T> snapshot = [];
        foreach (T item in collection)
        {
            snapshot.Add(item);
            if (EqualityComparer<T>.Default.Equals(item, expected))
            {
                return;
            }
        }

        ThrowAssertContainsItemFailed(message, expectedExpression, collectionExpression, snapshot);

In AllItemsAreUnique, the duplicate value is formatted via Assert.ReplaceNulls(current) which does not escape newlines or apply truncation/quoting. Since this PR introduces Assert.FormatValue specifically to keep failure messages single-line per parameter and consistent, consider using Assert.FormatValue(current) (or equivalent) for the duplicate parameter value.

IsSubsetOf builds missingElements via Convert.ToString(item, ...) and string.Join. If an element is null, Convert.ToString returns null and string.Join will render it as an empty string, losing information in the failure message. Consider mapping nulls explicitly (e.g., item is null ? "null" : ...) or using the new Assert.FormatValue/Assert.ReplaceNulls helpers for each element before joining.